Current multi-layer network architectures using a Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) standard are based on anchor/booster and carrier aggregation frameworks. Current 3GPP Release 12 solutions support inter-site traffic offload/aggregation between a Master Cell or Master Evolved Node B (MeNB) and a Secondary Cell or Secondary eNodeB (SeNB). Here the LTE user plane connection is anchored at the Master eNB and user plane traffic is offloaded to the SeNB below the Packet Data Convergence Protocol (PDCP) layer. 3GPP Release 12 prescribes several features that allow for efficient operation for inter site traffic offload and aggregation.
Packet Data Convergence Protocol (PDCP) Status reporting on the secondary link to avoid transmit buffer buildup is one such feature. When traffic is offloaded via a different link from the LTE PDCP layer, the status of successful completion or no completion of PDCP packets offloaded via the secondary path may be signaled to the aggregation control engine at the PDCP layer. This information may be obtained, per the current standard, in Radio Link Control Acknowledged-mode (RLC AM), and Packet Data Convergence Protocol) (PDCP) status/acknowledgment (ACK) in normal communication may be derived from receiver to the transmitter entity using RLC sequence number (SN) Status transfer message, which is not able to incorporate the information of offloaded PDCP packets. In the absence of PDCP status report on successful completion for offloaded packets, the transmitter cannot clear its buffer in an efficient manner. While the transmitter PDCP entity may clear its buffer based on PDCP discard timer, the typical settings of this timer may result in a large number of PDCP packets being stored in the transmit buffer, even though they have already been delivered successfully via the offloaded path. This can result in transmitter buffer overload, unnecessary forwarding of PDCP packets during handover or unnecessary transmissions during connection re-establishment due to, for example, Radio Link Failure (RLF), Handover (HO) failure, integrity check failure, Radio Resource Control (RRC) connection reconfiguration failure, and so on.
PDCP Status reporting on the secondary link to avoid Hyper Frame Number (HFN) desynchronization is another feature. Additionally, PDCP status reporting for offloaded packets is required for PDCP Sequence Number (SN) control in order to avoid Hyper Frame Number (HFN) desynchronization during inter-site aggregation. Due to traffic offload on multiple links, the PDCP packets may arrive out-of-order at the receiver, and the receiver has to reorder the PDCP before delivering them in-sequence to the PDCP receiver. Since the PDCP SN space is limited based on the number of bits used for the SN, HFN desynchronization is possible if the transmitter does not control the PDCP SN in flight because of this inability to have up-to-date information. For this reason and to avoid over flow of the reordering buffer, the transmitter should ensure that no more than half of PDCP SN space is introduced in flight at the transmit PDCP entity.
Flow Control of Traffic Offloaded to Secondary Cells is yet another feature. How and when the PDCP packets are offloaded to the secondary link also may be managed, so as to avoid buffer build up or overflow at the SeNB. Dynamic offload control is also required for enhancing inter-site aggregation performance.
Dual Connectivity Enhancements to Support Inter-Site Aggregation is a further feature. 3GPP Release 12 supports PDCP status reporting and flow control via the GTP-U interface between the MeNB and the SeNB for efficient traffic offloading operation. Here, the SeNB can use RLC AM to derive PDCP packet delivery status and report it to MeNB via a downlink (DL) DATA DELIVERY STATUS. Further, support for traffic flow control is also supported on this interface. Using network based PDCP status reports, flow control and feedback mechanism is more efficient than relying on user equipment (UE) support, as information can be exchanged more frequently and avoids UE complexity, power consumption and air interface overhead. For LTE WLANN Aggregation (LWA), the Xw interface may be utilized instead of the X2 interface, and a WLAN Termination (WT) entity instead of a SeNB.
Extensions to General Multi-RAT Architectures is yet a further feature. Similar extensions are also required for a more general LTE anchored multiple Radio Access Technology (multi-RAT) architectures, such as those envisioned for Wireless Local Area Network (WLAN) in accordance with an Institute of Electrical and Electronics Engineers (IEEE) 802.11 Wireless Local Area Network or future Fifth Generation (5G RAT) aggregation based on LTE anchored multi-radio access networks. In particular, the 3GPP Release 13 LTE-WLAN Aggregation (LWA) solution, with ongoing work item in 3GPP RAN2 and RAN3, is based on dual connectivity framework adopted for WLAN, so that WLAN Termination (WT) replaces the SeNB, said WT communicates with WLAN APs or ACs and mechanisms for network based delivery status reports, flow control and feedback. Such solutions, however, require changes to at the WLAN access point (AP) or access controller (AC) to support the interface to the eNB. Ensuring broad deployments of LWA may involve consideration of alternatives that can minimize impact to legacy WLAN network deployments. Further changes involved at the AP to support a network based solution should be considered.
It will be appreciated that for simplicity and/or clarity of illustration, elements illustrated in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, if considered appropriate, reference numerals have been repeated among the figures to indicate corresponding and/or analogous elements.